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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



ETSI 



ETSI TS 186 020 V2.1.1 (2009-12) 



Scope 



The present document specifies interoperability tests for IMS-based IPTV system for NGN Release 2. It covers the use 
of main IPTV functionality via different methods. Interoperability test descriptions have been specified following the 
ETSI IPT test specification framework described in EG 202 568 [i.l] and interoperability testing methodology defined 
in EG 202 237 [i.2], i.e. interoperability testing with a conformance relation. Each interoperability test description 
includes an end user test sequence as well as a table for checking of high level message flows at key standardized 
reference points in the TISPAN IMS-based IPTV infrastructure [1] and [2]. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 182 027 (V2.4.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 

subsystem". 

[2] ETSI TS 183 063 (V2.4.2): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[3] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 

[4] IETF RFC 3261: " SIP: Session Initiation Protocol". 

[5] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[6] IETF RFC 3376: "Internet Group Management protocol, Version 3". 

[7] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[8] ETSI TS 183 048: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control System (RACS); Protocol 
Signalling flows specification; RACS Stage 3". 
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[9] 

[10] 
[11] 



ETSI TS 183 017 (V2.3.1): "Telecommunications and Internet converged Services and Protocols 
for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF); Protocol specification". 

ETSI TS 102 539: "Digital Video Broadcasting (DVB); Carriage of Broadband Content Guide 
(BCG) information over Internet Protocol (IP)". 

ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalling of TV- Anytime 
information in DVB transport streams". 



2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 



[i.l] 
[i.2] 

[i.3] 



ETSI EG 202 568: "Methods for Testing and Specification (MTS); Internet Protocol Testing 
(IPT); Testing: Methodology and Framework". 

ETSI EG 202 237: "Methods for Testing and Specification (MTS); Internet Protocol Testing 
(IPT); Generic approach to interoperability testing". 

K. Taniguchi and K. Ishikawa: "MSF IMS-based IPTV Test Plan for GMI 2008", Multi Service 
Forum (MSF) contribution 2008.169.06. 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP 3 rd Generation Partnership Project 

A-RACS Access - Resource and Admission Control Subsystem 

AAA AA-Answer 

AAR AA-Request 

AS (IMS) Application Server 

BC Broadcast 

CF (Test) Configuration 

CoD Content On Demand 

CoDS Content on Demand Server 

CSCF Call Session Control Function 

EPG Electronic Program Guide 

FEC Forward Error Correction 

I-CSCF Interrogating CSCF 

IGMP Internet Group Management Protocol 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IP EN IP Edge Node 

IPTV Internet Protocol Television 

MCF Media Control Function 

MDF Media Delivery Function 

MLD Multicast Listener Discovery 

nPVR network-side Personal Video Recorder 

P-CSCF Proxy CSCF 

PO Point of Observation 

PVRS Personal Video Recorder Server 

RCEF Resource Control Enforcement Function 

RTSP Real Time Streaming Protocol 

S-CSCF Serving CSCF 

SIP Session Initiation Protocol 

SDP Session Description Protocol 
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SCF Service Control Function 

SDF Service Discovery Function 

SPDF Service-based Policy Decision Function 

SSF Service Selection Function 

STA Session-Termination-Answer 

STR Session-Termination-Request 

T&A Transport and Access 

TCP Transmission Control Protocol 

TD Test Description 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UE User Equipment 

UPSF User Profile Server Function 

URI Uniform Record Identifier 



4 IMS-based IPTV Interoperability Test Specification 

4.1 Introduction 

The IMS-based IPTV interoperability test descriptions (TDs) defined in the following clauses are mainly derived from 
MSF 2008.169.06 [i.3], TS 183 063 [2] and TS 182 027 [1]. More specifically, these TDs focus on SIP/SDP [5], HTTP 
[7], RTSP [4], IGMP [6] related messaging procedures without RACS described in clauses 5, 6, 7, 8 and 1 1 of 
TS 183 063 [2]. TDs where RACS is involved are described in part in TS 183 048 [8]. 

The use of FLUTE and DVBSTP transport protocols on Xa reference point as well as IPv6 MLD are at this point not 
within the scope of the present document. 

4.2 Test Prerequisites 
4.2.1 IP Version and protocols 

4.2.1.1 IP 

The present document assumes that IP-based protocols all use IPv4. 

4.2.1.2 RTSP 

The present document assumes RTSP [3] messages are sent only via TCP. 

4.2.1.3 SIP 

The present document assumes that all SIP [4] messages are sent via UDP to ensure retransmission procedures based on 
SIP only and to simplify the match procedure between the message flows and real network capture. 

4.2.1.4 IGMP 

The present document assumes that IPTV aware UE requests for multicast group use IGMPv3 [6]. 

4.2.1.5 Media transport 

The present document assumes that content is transported using one of the following transport technologies: MPEG2TS 
encapsulation or direct RTP transport (e.g. H264 over RTP). Further it is assumed that transport of IPTV content within 
MPEG2-TS layer over RTP and UDP is performed according the procedures defined in TS 102 034 [5]. 
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4.2.2 Authentication and Security 

4.2.2.1 SIP 

The present document assumes that no SIP -based authentication is performed. 

4.2.2.2 HTTP 

Personalized service selection is out of the scope of the document. Hence, no HTTP authentication is required from the 
UE toward SSF or SCF. Also no authentication proxy is needed between the UE and the SCF. 

4.2.3 Supported Options 

4.2.3.1 Signalling Compression 

"No SigComp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 

4.2.3.2 SIP Provisional Message Reliability 

The present document assumes there is no use of SIP lOQrel option tag. 

4.2.3.3 SIP precondition option tag 

The present document assumes there is no use of SIP precondition option tag. 

4.2.3.4 SIP timer option tag (Session Timers) 

The present document assumes there is use of SIP timer option tag which supports session timer extension. The 
inclusion of this option tag in a Supported header field of a SIP request or response indicates that the UE is capable of 
performing refreshes. The inclusion of this option tag in a Require header of a SIP request indicates that the IMS core 
network should understand the session timer extension to process the request. Its inclusion in a Require header field of a 
SIP response indicates that the UE should look for the Session-Expires header field in the response and process it 
according to [4] . 

4.2.4 Content related options 

4.2.4.1 Encrypted contents 

The present document assumes that encryption is not used for CoD or BC content provisioning. 

4.2.4.2 Digital Rights Management 

The present document assumes DRM is not used for CoD or BC content provisioning. 

4.2.4.3 FEC 

The present document assumes that FEC disabled for CoD and BC content provisioning. 

4.2.5 Service discovery 

Service discovery should follow the procedures defined in TS 102 539 [10] and TS 102 323 [11]. 



ETSI 



10 



ETSI TS 186 020 V2.1.1 (2009-12) 



4.2.6 Miscellaneous 

4.2.6.1 Network Address Translation (NAT) and Firewall function 

The present document assumes there is neither NAT nor Firewall function activated. 



4.3 



Test Architecture 



In figure 1, various nodes of an IMS-based IPTV system that pertain to testing are introduced. For each node 
configuration is described and relevant points of observation (POs) are identified. Based on these nodes a static test 
architecture is defined. Figure 1 shows the abstract test architecture of an IMS -based IPTV system based on the general 
IPTV architecture defined in [2], [8] and [9]. 
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Figure 1 : IMS-based IPTV test architecture (referred as CFJMSJPTV) 

In figure 1, each node groups different IPTV logical functions. Interfaces within each node are considered internal and 
not taken into account in conformance criteria. It may however be of interest to also monitor these internal interfaces for 
debugging purposes. 

Reference points (Ut, e2 and y2 towards BC-MCF) in dotted line are not in the scope of the present document. 

NOTE: In a real IMS-based IPTV system some of the nodes shown in Figure 1 may also be collocated in the 
same equipment. In this case it is however still assumed that their connecting interfaces are still 
available for monitoring purposes 

Each node framed with a solid line is considered an Equipment under Test (EUT) in the context of the ETSI 
interoperability testing methodology [i.2]. The collection of all EUTs makes up the System Under Test (SUT). Dashed 
nodes indicate other equipment, i.e. support nodes, required to execute at least some of the tests. The latter nodes are 
considered not to be part of the SUT. 
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4.3.1 



IPTV Nodes 



4.3.1.1 Core IMS 

This node contains P-CSCF, I-CSCF and S-CSCF functions as well as potentially (a part of) the UPSF. 



4.3.1.1.1 



Relevant Reference Points 



The Gm reference point between the IMS Core and the IP aware UE is used as a point of observation (PO) for testing 
purposes. The ISC reference point is between the IMS Core and IPTV AS and used as a PO for testing purposes. The y2 
reference point is between the IMS Core and the PVRS and CoDS and used as a PO for testing purposes. The Gq' 
reference point is between the IMS Core and T&A and is used as a PO for testing purposes. 

4.3.1.1.2 Node Configuration 

The Core IMS should be configured to support the pre-requisites outlined in clause 4.2. 
The UPSF should be configured with the following user identities 



Private Identity 


Public Identity 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default Public 
Identity 


Filter criteria 


userlPTV_priv 


userlPTV 


na 


1 


contact IPTV AS 



4.3.1.2 IPTV aware UE 

4.3.1.2.1 Relevant Reference Points 

The Gm interface is used as a PO for interoperability tests towards the IMS Core. 

The Xa interface is used as a PO for interoperability tests towards the IPTV AS. 

The Xc and Xd (Dj) interfaces are used as POs for interoperability tests towards the PVRS, CoDS and TV Head End. 

4.3.1 .2.2 Node Configuration 

The IP aware UE should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.3 I PTV Application Server (AS) 

This node contains SSF, SDF, and SCF functions as well as may contain also (a part of) the UPSF. 



4.3.1.3.1 



Relevant Reference Points 



The Xa interface is used as a PO towards the IPTV aware UE whereas the ISC interface is used as a PO towards the 
IMS Core. 

4.3.1 .3.2 Node Configuration 

The IPTV AS should be configured to support the pre-requisites outlined in clause 4.2. 

The media content available in the PVRS, CoDS and TV Head End has to be described within the IPTV AS. 

IPTV specific data information associated with the user has to be described within the IPTV AS [9]. 

4.3.1 .4 Content on Demand Server (CoDS) 

This node contains CoD-MCF and CoD-MDF functions. 
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4.3.1.4.1 Relevant Reference Points 



The y2 reference point is used as a PO between the Core IMS and the CoDS. The Xd reference point is used as PO 
between the UE and the CoDS. 

4.3.1.4.2 Node Configuration 

The CoDS should be configured to support the pre-requisites outlined in clause 4.2. 
The media contents as described in the EPGs have to be available on the CoDS. 

4.3.1 .5 Personal Video Recorder Server (PVRS) 

This node contains nPVR-MCF and nPVR-MDF functions. 

4.3.1.5.1 Relevant Reference Points 

The y2 reference point is used as a PO between the Core IMS and the PVRS. The Xd reference point is used as PO 
between the UE and the PVRS. 

4.3.1.5.2 Node Configuration 

The PVRS should be configured to support the pre-requisites outlined in clause 4.2. 
The media contents as described in the EPGs have to be available on the PVRS. 



4.3.1 .6 Transport and Access (T&A) 



This node contains transport control and processing functions, A-RACS, SPDF, NASS and RCEF. The latter is located 
in the IP-Edge Node. 

4.3.1.7 Relevant Reference Points 

The Xd, Xc and Dj reference points are used as POs between the UE and the transport node. 
Gq' reference point is used as Pos between SPDF and CORE IMS. 

4.3.1 .8 Node Configuration 

The T&A should be configured to support the pre-requisites outlined in clause 4.2. 

Regarding multicast support, the function has to implement IGMPv3, IGMPv2 with SSM (source specific mapping) and 
in case the multicast sources are not directly connected a CORE network a multicast protocol (e.g.: PIM). 

4.3.2 External Nodes 

This clause lists nodes which are required for performing some of the interoperability tests but not consider to be part of 
the SUT, i.e. supporting equipment required for the execution of tests. 

4.3.2.1 TV Head End 

This node contains BC-MDF and BC-MCF functions. 

4.3.2.2 Relevant Reference Points 

The Xd reference point is used as PO between the UE and the TV Head End. 

y2 reference point is used between CORE IMS and BC-MCF. It is not a PO so far. 
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4.3.2.2.1 Node Configuration 

The TV Head End should be configured to support the pre-requisites outlined in clause 4.2. 
TV End Head should provide at least one BC channel unconditionally. 

4.3.3 Summary of interfaces and protocols 

Figure 1 includes also IPTV reference points to be monitored in interoperability testing. 

Figure 2 identifies again the relevant reference points and provides more information about the protocols they use. 
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Figure 2: Summary of relevant reference points and protocols 

In addition, Gq' between IMS Core and TA carries diameter protocol. 

4.3.4 Method 1 and Method 2 

In the interoperability test descriptions defined in the present document, two methods regarding the procedures using 
RTSP for IMS-based IPTV are used. More information on these methods is available in clause 7 and Annex Q of [2]. 



4.4 Test Descriptions 



This clause defines IMS-based IPTV interoperability test descriptions (TD) for systems composed of equipment by 
different vendors. Each TD includes a test sequence describing user interactions with IPTV equipment as well as 
messages exchanged between IPTV equipment at selected standardized reference points. 

TD identifiers are constructed from a test suite identifier, a test group identifier and a test number. Table 1 summarizes 
the main identifiers used in the present document. 
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Table 1 : Summary of TD identifier prefixes 



Test Description Identifier Prefix 


Scope of the test 


TD IMS IPTV ADS 


Service attachment, discovery and selection 


TD IMS IPTV BC 


Broadcast TV 


TD IMS IPTV BC1 


Broadcast TV with trick mode using method 1 


TD IMS IPTV BC2 


Broadcast TV with trick mode using method 2 


TD IMS IPTV CoD1 


Content on Demand using method 1 


TD IMS IPTV CoD2 


Content on Demand using method 2 


TD IMS IPTV nP1 


nPVR using method 1 


TD IMS IPTV nP2 


nPVR using method 2 



4.4.1 Service Attachment, Service Discovery and Selection 

In the following TDs, we consider step 1 of the IPTV Aware UE start-up procedure, i.e. Network attachment (UE to 
NASS), as being out of the scope of the test. 

4.4.1 .1 Manual configuration of SSF information in pull mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV ADS 0001 (MSF S3A-0101) 


Summary: 


UE displays EPG with manual SSF address configuration 


References: 


TS 182 027 [1] clause 8.2; TS 183 063 [2] clause 6.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


Pre-test 
conditions: 


• IPTV AS is configured not to act as a third-party registrar (push mode is disabled) 

• UE is configured statically with SSF information 

• UE and IPTV AS support the same EPG format 


Test Sequence: 


Step 




1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 
















1 




» 














User starts UE 


2 
















SIP 


UE sends SIP REGISTER to CORE via Gm 






3 


SIP 


CORE sends SIP 200 OK to UE via Gm 






4 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








5 

6 

7 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

User requests EPG 

UE displays EPG 


<— 


— » 













Steps 4 and 5 may be repeated multiple times. Each HTTP message pair carries information (EPG) different from 
vendors. 
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4.4.2.1 Automatic provisioning of SSF in pull mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV ADS 0002 (MSF S3A-0101) 


Summary: 


UE displays EPG with automatic SSF provision in pull mode 


References: 


TS 182 027 [1] clause 8.2; TS 183 063 [2] clauses 5.1.2.2 and 6.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


Pre-test 
conditions: 


• IPTV AS is configured not to act as a third-party registrar (push mode is disabled) 

• Core IMS is configured to forward service attachment information request to IPTV 
AS 

• UE is configured to request the EPG 

• UE and IPTV AS support the same EPG format 


Test Sequence: 


Step 




1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 








1 




^ 
















2 
















SIP 


UE sends SIP REGISTER to CORE via Gm 






3 


SIP 


CORE sends SIP 200 OK to UE via Gm 






2 


SIP 


UE sends SIP SUBSCRIBE to CORE via Gm 






3 


SIP 


CORE sends SIP SUBSCRIBE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 


SIP 


AS sends SIP NOTIFY to CORE via ISC 




7 


SIP 


CORE sends SIP NOTIFY to UE via Gm 






8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 


SIP 


CORE sends SIP 200 OK to AS via ISC 




10 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








11 


HTTP 


AS sends HTTP 200 OK to UE via Xa ( 1 to n 
times) 








12 
13 




» 

i 














User requests EPG 
UE displays EPG 



Steps 10 and 1 1 can be repeated multiple times. Each HTTP message pair carries information different from vendors. 
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4.4.2.2 Automatic provisioning of SSF in push mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV ADS 0003 (MSF S3A-0101) 


Summary: 


UE can display EPG with automatic SSF provision in push mode 


References: 


TS 182 027 [1] clause 8.2; TS 183 063 [2] clauses 5.1.2.1 and 6.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


Pre-test 
conditions: 


• IPTV AS is configured to act as a third-party registrar (push mode enabled) 

• UPSF is configured to provide SSF information to SDF 

• UE is configured for SSF provision in push mode 

• UE and IPTV AS support the same EPG format 


Test Sequence: 


Step 




1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 
















1 




» 














User starts UE 


2 
















SIP 


UE sends SIP REGISTER to CORE via Gm 






3 


SIP 


CORE sends SIP 200 OK to UE via Gm 






4 


SIP 


CORE sends SIP REGISTER to AS via ISC 




5 


SIP 


AS sends SIP 200 OK to CORE via ISC 




6 


SIP 


AS sends SIP MESSAGE to CORE via ISC 




7 


SIP 


CORE sends SIP MESSAGE to UE via Gm 






8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 


SIP 


CORE sends SIP 200 OK to AS via ISC 




10 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








11 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








12 
13 




» 

i 














User requests EPG 
UE displays EPG 



Steps 10 and 1 1 can be repeated multiple times. Each HTTP message pair carries information different from 
vendors. 
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4.4.2 Broadcast TV 



4.4.2.1 Session initiation without RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0001 (S3A-0201) 


Summary: 


User requests to watch broadcast TV channel 


References: 


TS 1 82 027 [1 ] clause 8.3.1 ; TS 1 83 063 [2] clauses 5.1 .3.1 and 8.1 .2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• EPG has at least one broadcast channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 


Test Sequence: 


Step 




1 


User requests to watch a broadcast TV channel 


2 


Verify that UE displays the selected broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 








1 




> 














User requests to watch a broadcast TV channel 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 


SIP 


UE sends SIP ACK to CORE via Gm 






7 


SIP 


CORE sends SIP ACK to AS via ISC 




8 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




y 
10 




4 












SIP 


UE displays the selected broadcast TV channel 
UE sends SIP INFO to CORE via Gm 






11 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after IGMP join message. If the channel is changed again within the 
delay, the INFO message is not sent out. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending SIP ACK. 
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4.4.2.2 Channel Zapping without RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0002(S3A-0301) 


Summary: 


User changes to a HD channel while watching a SD broadcast TV 


References: 


TS 1 82 027 [1 ] clause 8.3.4; TS 1 83 063 [2] clauses 5.1 .3.5 and 8.1 .2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE is registered in Core IMS and displaying a broadcast TV channel 
(see TDJMS_IPTV_BC_0001) 

• The EPG has at least 2 broadcast channels 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 


Test Sequence: 


Step 




1 


User changes to another broadcast TV channel 


2 


Verify that UE displays the other broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 
















1 




» 














User changes to another broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


SIP 


UE sends SIP re-INVITE to CORE via ISC 
(optional) 






4 


SIP 


CORE sends SIP re-INVITE to AS via ISC 
(optional) 




5 


SIP 


AS sends SIP OK to CORE via ISC (optional) 




6 


SIP 


CORE sends SIP OK to UE via ISC (optional) 






7 


IGMP 


UE sends IGMP JOIN INFO to T&A via Dj 




8 


















Verify that UE displays the other broadcast TV 
channel 




9 
















SIP 


UE sends SIP INFO to AS via ISC 






10 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after an IGMP JOIN message. If the channel is changed again within 
the delay, the SIP INFO message is not sent out. 
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4.4.2.3 Session termination without RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0003(S3A-0401) 


Summary: 


User quits watching broadcast TV 


References: 


TS 182 027 [1] clause 8.4.1 ; TS 183 063 [2] clauses 5.1.4.2 and 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying a broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• EPG has at least one broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 


Test Sequence: 


Step 




1 


User quits watching the broadcast TV channel 


2 


Verify that the UE does not display the broadcast TV channel anymore 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 








1 




j 














User quits watching the broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


















UE does not display the broadcast TV channel 
anymore 




4 
















SIP 


UE sends SIP BYE to CORE via Gm 






5 


SIP 


CORE sends SIP BYE to AS via ISC 




6 


SIP 


AS sends SIP 200 OK to CORE via ISC 




7 


SIP 


CORE sends SIP 200 OK to UE via Gm 











4.4.2.4 Session initiation with RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0004 


Summary: 


User requests to watch broadcast TV channel using QoS 


References: 


TS 182 027 [1] clause 8.3.1; TS 183 063 [2] clauses 5.1.3.1 and 8.1.2.1, TS 183 017 [9] 
clauses 5.1.1 and 5.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• EPG has at least one broadcast channel 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured to request QoS 


Test Sequence: 


Step 




1 


User requests to watch a broadcast TV channel 


2 


Verify that UE displays the selected broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




> 














User requests to watch a broadcast TV channel 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 
(SDP Bandwidth "b=" option is populated 
through EPG related information or static 
configuration) 






3 


SIP 


CORE sends SIP 100 Trying to UE via Gm 






4 


Diameter 


CORE sends AAR to T&A via Gq' 




5 


Diameter 


T&A sends AAA to CORE via Gq' 
(Result-Code = DIAMETER SUCCESS) 




6 


SIP 


CORE sends SIP INVITE to AS via ISC 




7 


SIP 


AS sends SIP 200 OK to CORE via ISC 




8 


Diameter 


CORE sends AAR to T&A via Gq' 




9 


Diameter 


T&A sends AAA to CORE via Gq' 
(Result-Code = DIAMETER SUCCESS) 




10 


SIP 


CORE sends SIP 200 OK to UE via Gm 






11 


SIP 


UE sends SIP ACK to CORE via Gm 






12 


SIP 


CORE sends SIP ACK to AS via ISC 




13 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




14 

15 




< 












SIP 


UE displays the selected broadcast TV channel 
UE sends SIP INFO to CORE via Gm 






16 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after IGMP join message. If the channel is changed again within the 
delay, the INFO message is not sent out. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending SIP ACK. 

The diagram above shows a two phases method on Gq' reference point (see clause 5.1.1 of [10]). Steps 5 request is for 
resource reservation, step 10 for resource commitment. Alternatively, steps 10 and 1 1 could be omitted if step 5 
requests resource commitment (Flow-Status is different of DISABLED). 

4.4.2.5 Channel Zapping with RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0005 


Summary: 


User changes to a HD channel while watching SD broadcast TV using QoS 


References: 


TS 182 027 [1] clause 8.3.4; TS 183 063 [2] clauses 5.1.3.5 and 8.1.2; TS 183 017 [9] 
clauses 5.1.2 and 5.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE is registered in Core IMS and displaying a broadcast TV channel 
(see TDJMS_IPTV_BC_0001) 

• The EPG has at least 2 broadcast channels 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured to request QoS 


Test Sequence: 


Step 




1 


User changes to another broadcast TV channel 


2 


Verify that UE displays the other broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




> 














User changes to another broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


SIP 


UE sends SIP re-INVITE to CORE via ISC 






4 


Diameter 


CORE sends AAR to T&A via Gq' 




5 


Diameter 


T&A sends AAA to CORE via Gq' 




6 


SIP 


CORE sends SIP re-INVITE to AS via ISC 




7 


SIP 


AS sends SIP OK to CORE via ISC 




8 


Diameter 


CORE sends AAR to T&A via Gq' 




9 


Diameter 


T&A sends AAA to CORE via Gq' 




10 


SIP 


CORE sends SIP OK to UE via ISC 






11 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




12 


















Verify that UE displays the other broadcast TV 
channel 




13 
















SIP 


UE sends SIP INFO to AS via ISC 






14 


SIP 


CORE sends SIP INFO to AS via ISC 





















The diagram above shows a two phases method on Gq' reference point (see clause 5.1.1 of [10]). Step 4 request is for 
resource reservation, step 8 for resource commitment. Alternatively, steps 8 and 9 could be omitted if step 4 requests 
resource commitment (Flow-Status is different of DISABLED). 

4.4.2.6 Session termination with RACS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0006 


Summary: 


User quits watching broadcast TV using QoS 


References: 


TS 182 027 [1] clause 8.4.1 ; TS 183 063 [2] clauses 5.1.4.2 and 7.2.1 ; TS 183 017 [9] 
clauses 5.1.3 and 5.2.3 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying a broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• EPG has at least one broadcast TV channel 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured to request QoS 


Test Sequence: 


Step 




1 


User quits watching the broadcast TV channel 


2 


Verify that the UE does not display the broadcast TV channel anymore 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




> 














User quits watching the broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


















UE does not display the broadcast TV channel 
anymore 




4 
















SIP 


UE sends SIP BYE to CORE via Gm 






5 


Diameter 


CORE sends STR to T&A via Gq' 




6 


Diameter 


T&A sends STA to CORE via Gq' 




7 


SIP 


CORE sends SIP BYE to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 



















4.4.3 Broadcast TV with trick-play using Method 1 

More information about Method 1 is given in clause 4.3.4. 



4.4.3.1 Initiate trick-play on a live broadcast channel 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC1 0001 (S3A-0501) 


Summary: 


User initiates trick mode while watching a broadcast TV channel 


References: 


TS 182 027 [1] clause 8.3.5; TS 183 063 [2] clauses 5.1.3.3.1 and 8.1.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying a trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests a pause on the broadcast TV channel 


2 


Verify that the UE freezes the image of the broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests a pause on the broadcast TV 
channel 




2 














SIP 


UE sends SIP RE-INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP RE-INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


IGMP 


UE sends IGMP LEAVE to T&A via Dj 




15 


















UE freezes the image of the broadcast TV 
channel 





















It is acceptable to generate SIP UPDATE instead of re INVITE requests. In that case SIP ACK requests should not be 
sent. 

There is no strict sequence of SIP and IGMP messages. The IGMP LEAVE message may be sent before or after 
sending SIP ACK. 

4.4.3.2 Play in trick-play mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC1 0002(S3A-0601) 


Summary: 


User requests the normal play mode on a broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests play on the paused broadcast TV channel 


2 


Verify that UE displays the recorded broadcast TV channel content 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests play on the paused broadcast TV 
channel 




2 
















RTSP 


UE sends RTSP PLAY to CoDS via Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















Verify that UE displays the recorded broadcast 
TV channel content 





















A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 



4.4.3.3 Simple fast forward trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC1 0003(S3A-0601) 


Summary: 


User requests fast forward on a paused broadcast TV channel in trick play mode 
without reaching the end of recording 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on the paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PLAY (scale +2) to CoDS via 
Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















UE displays recorded broadcast TV channel in 
fast forward mode. 





















A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 
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4.4.3.4 Fast backward trick-play to beginning of recorded content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC1 0004(S3A-0701) 


Summary: 


User requests fast backward on a paused broadcast TV channel in trick play mode 
until the beginning of the recording is reached 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast TV channel 


Test Sequence: 


Step 




1 


User requests x2 fast backward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast backward 
mode 


3 


Verify that UE stops display when beginning of recording is reached 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast backward on the paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY (scale -2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays recorded broadcast TV channel in 
fast backward mode 




7 


















UE stops display when beginning of recording is 
reached 
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4.4.3.5 Fast forward to move from trick-play to live broadcast mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC1 0005(S3A-0801) 


Summary: 


User requests fast forward until the end of recording is reached and moves from trick 
play to live broadcast TV channel 


References: 


TS 182 027 [1] clause 8.3.6; TS 183 063 [2] clauses 5.1.3.3.2, 7.2.1 and 8.1.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• CoDS is recording the trick play enabled broadcast TV channel 

• UE is configured to change to live broadcast automatically after trick play ends 


Test Sequence: 


Step 




1 


User requests x2 fast forward on a paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


3 


Verify that UE displays live broadcast TV channel when end of recording is 
reached 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on a paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















UE displays recorded broadcast TV channel in 
fast forward mode 


5 
















RTSP 


CoDS sends RTSP ANNOUNCE to UE via Xc 










6 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 






























7 
















IGMP 


UE sends IGMP JOIN to T&A via Dj 




8 


SIP 


UE sends SIP REINVITE to CORE via Gm 






9 


SIP 


CORE sends SIP REINVITE to AS via ISC 




10 


SIP 


AS sends SIP BYE to CORE via ISC 




11 


SIP 


CORE sends SIP BYE to CoDS via y2 






12 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 




14 


SIP 


AS sends SIP 200 OK to CORE via ISC 




15 


SIP 


CORE sends SIP 200 OK to UE via Gm 






16 


SIP 


UE sends SIP ACK to CORE via Gm 






17 


SIP 


CORE sends SIP ACK to AS via ISC 




18 


















UE displays live broadcast TV channel when 
end of recording is reached 
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Upon receipt of the end-of-stream indication the CoDS sends in step 5 an RTSP ANNOUNCE to the UE with an 
indication that the end-of-stream has been reached. In case of BC sessions with trick-play, if the UE receives an RTSP 
ANNOUNCE request with an end-of-stream indication, the UE may initiate a session modification procedure in order 
to go back to a normal BC session in multicast mode (this is the case described above) or may alternatively take other 
actions (e.g. rewind, pause, terminate session, etc.). 

There is a delay between the UE receiving the RTSP ANNOUCE in step 5 and sending the SIP relNVITE in step 8. 

It is acceptable to generate SIP UPDATE instead of SIP relNVITE requests. In that case SIP ACK requests should not 
be sent. 

Before the RTSP PLAY message in step 2 a RTSP PAUSE message may be sent. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending the SIP ACK request. 

4.4.4 Broadcast TV with trick-play using Method 2 

More information about Method 2 is given in clause 4.3.4. 

4.4.4.1 Initiate trick-play on a live broadcast channel 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC2 0001 (S3A-0502) 


Summary: 


User initiates trick mode while watching a broadcast TV channel 


References: 


TS 1 82 027 [1 ] clause 8.3.5; TS 1 83 063 [2] clauses 5.1 .3.3.1 and 8.1 .2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying a trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• EPG has at least one broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests to pause on the broadcast TV channel 


2 


Verify that the UE freezes the image of the broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests to pause on the broadcast TV 
channel 


5 




2 
















SIP 


UE sends SIP RE-INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP RE-INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP REINVITE to CORE via Gm 






19 


SIP 


CORE sends SIP REINVITE to AS via ISC 




20 


SIP 


AS sends SIP REINVITE to CORE via ISC 




21 


SIP 


CORE sends SIP INVITE to CoDS via y2 






22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 




28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


IGMP 


UE sends IGMP LEAVE to T&A via Dj 




30 


SIP 


CORE sends SIP ACK to CoDS via y2 






31 


















UE freezes the image of the broadcast TV 
channel 

























The RTSP DESCRIBE message in step 14 is sent in case the UE did not get content delivery description information 
(from the SSF or from the AS-IPTV/SS-MCF-IPTV during the SIP session initiation), 

It is acceptable to generate SIP UPDATE instead of re-INVITE requests. In that case SIP ACK requests should not be 
sent. 

There is no strict sequence of SIP and IGMP messages. The IGMP LEAVE message may be sent before or after 
sending SIP ACK. 
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4.4.4.2 Play in trick-play mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC2 0002 (S3A-0602) 


Summary: 


User requests the normal play mode on a broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests to play the current paused broadcast TV channel in trick 
play mode 


2 


Verify that UE displays the recorded broadcast TV channel 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests to play the current paused 
broadcast TV channel in trick play mode 




2 
















RTSP 


UE sends RTSP PLAY (scale : +1) to CoDS via 
Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















Verify that UE displays recorded broadcast TV 
channel 
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4.4.4.3 Simple fast forward trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC2 0003 (S3A-0602) 


Summary: 


User requests fast forward on a paused broadcast TV channel in trick play mode 
without reaching the end of recording 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on the paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 










3 
















RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 




i 














UE displays recorded broadcast TV channel in 
fast forward mode 



A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 
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4.4.4.4 Fast backward trick-play to beginning of recorded content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC2 0004 (S3A-0702) 


Summary: 


User request a fast backward on a paused broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• CoDS is recording the trick play enabled broadcast TV channel 


Test Sequence: 


Step 




1 


User requests x2 fast backward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast backward 
mode 


3 


Verify that UE stops display when beginning of recording is reached 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Diagram 1 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast backward on the paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 
















RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 
















RTSP 


UE sends RTSP PLAY(scale -2) to CoDS via Xc 










5 
















RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays recorded broadcast TV channel in 
fast backward mode 


7 
















RTSP 


CoDS sends RTSP ANNOUNCE to UE via Xc 
(optional) 










8 
















RTSP 


UE sends RTSP 200 OK to CoDS via Xc 
(optional) 










9 


















UE stops display when beginning of recording is 
reached 





















In step 9, the UE is displaying a still image and then may switch to another mode. Handling of the start-of-stream in the 
ANNOUNCE message is up to the UE implementation. 
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4.4.4.5 Fast forward to move from trick-play to live broadcast mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC2 0005 (S3A-0802) 


Summary: 


User requests fast forward until the end of recording is reached and moves from trick 
play to live broadcast TV channel 


References: 


TS 182 027 [1] clause 8.3.6; TS 183 063 [2] clauses 5.1.3.3.2, 7.2.2 and 8.1.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast TV channel 

• UE is configured to change to live broadcast automatically after trick play ends 


Test Sequence: 


Step 




1 


User requests x2 fast forward on a paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


3 


Verify that UE displays live broadcast TV channel when end of recording is 
reached 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on a paused broadcast TV 
channel 




2 
















RTSP 


UE sends RTSP PLAY (scale +2)to CoDS via Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















UE displays recorded broadcast TV channel in fast forward 
mode 


5 
















RTSP 


CoDS sends RTSP ANNOUCE to UE via Xc 










6 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 










7 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




8 


















UE displays live broadcast TV channel when end of 
recording is reached 


9 
















RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 










10 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 










11 


SIP 


UE sends SIP REINVITE to CORE via Gm 






12 


SIP 


CORE sends SIP REINVITE to AS via ISC 




13 


SIP 


AS sends SIP BYE to CORE via ISC 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






14 
















SIP 


CORE sends SIP BYE to CoDS via y2 






15 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






16 


SIP 


CORE sends SIP 200 OK to AS via ISC 




17 


SIP 


AS sends SIP 200 OK to CORE via ISC 




18 


SIP 


CORE sends SIP 200 OK to UE via Gm 






19 


SIP 


UE sends SIP ACK to CORE via Gm 






20 


SIP 


CORE sends SIP ACK to AS via ISC 





















Upon receipt of the end-of-stream indication the CoDS sends in step 5 an RTSP ANNOUNCE to the UE with an 
indication that the end-of-stream has been reached. In case of BC sessions with trick-play, if the UE receives an RTSP 
ANNOUNCE request with an end-of-stream indication, the UE may initiate a session modification procedure in order 
to go back to a normal BC session in multicast mode (this is the case described above) or may alternatively take other 
actions (e.g. rewind, pause, terminate session, etc.). 

There is a delay between the UE receiving the RTSP ANNOUCE in step 4 and sending the RTSP TEARDOWN in step 
8 as well as SIP relNVITE in step 10. 

It is acceptable to generate SIP UPDATE instead of SIP relNVITE requests. . In that case SIP ACK requests should not 
be sent. 

Before the RTSP PLAY message in step 2 a RTSP PAUSE message may be sent. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending the SIP ACK request. 

4.4.5 Content on Demand (CoD) using Method 1 
4.4.5.1 Start CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0001 (S3A-1101) 


Summary: 


User requests to watch Content on Demand 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, Co 

• UE is re 

• EPG he 

• UE has 

• CoDS c 

• IMS CC 

• UE sup 


DS, Core IMS and IPTV AS are configured for method 1 

jgistered in Core IMS using userlPTV_priv identity 

s at least one CoD 

received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_0001/2/3) 

onfigured with CoD content 

IRE configured to forward CoD related SIP requests to AS IPTV 

ports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to watch a CoD 


2 


Verify that UE displays the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




i > 














User requests to watch a CoD 


2 
















SIP 


UE sends SIP OPTION to CORE via Gm 






3 


SIP 


CORE sends SIP OPTION to AS via ISC 




4 


SIP 


AS sends SIP OPTION to CORE via ISC 




5 


SIP 


CORE sends SIP OPTION to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 






11 


SIP 


CORE sends SIP INVITE to AS via ISC 




12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to CoDS via y2 






14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 




20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to CoDS via y2 






22 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










23 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










24 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 






25 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




26 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




27 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






28 




< 














UE displays the CoD 



The SIP OPTIONS message should be used for retrieving network parameters for the SDP payload in case that these 
parameters are not included in the SSF. 

When CoDS receives the very first RTSP PLAY message, the IPTV AS may send a SIP INFO message with 
CoDDeliveryStatus set to "Ongoing". 
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4.4.5.2 Pause CoD with trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0002 (S3A-1 201) 


Summary: 


User requests to pause a CoD using trick-play 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to pause CoD 


2 


Verify that UE freezes the image of the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to pause CoD 


2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 










3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
UE freezes the image of the CoD 


«— 













4.4.5.3 Play CoD in trick-play mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0003 (S3A-1 201) 


Summary: 


User requests play a CoD using trick-play 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, Co 

• UE is re 

• EPG h£ 

• UE is d 
(see TC 

• CoDS c 

• IMSCC 

• UEsup 


DS, Core IMS and IPTV AS are configured for method 1 

jgistered in Core IMS using userlPTV_priv identity 

s at least one CoD 

splaying paused CoD 

_IMS_IPTV_CoD1_0002) 

onfigured with CoD content 

IRE configured to forward CoD related SIP requests to AS IPTV 

ports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to play the paused CoD 


2 


Verify that UE displays the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






1 




j 














User requests to play the paused CoD 


2 




< 












RTSP 


UE sends RTSP PLAY to CoDS via Xc 










3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
Verify that the UE displays the CoD 











4.4.5.4 Simple fast forward of CoD using trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0004 (S3A-1 201) 


Summary: 


User requests fast forward on a paused CoD in trick play mode without reaching the 
end of recording 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying paused CoD 
(see TD_IMS_IPTV_CoD1_0002) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused CoD 


2 


Verify that UE displays images the CoD in fast forward mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on the paused 
CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays images the CoD in fast forward 
mode 
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4.4.5.5 Simple fast backward on CoD using trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0005 (S3A-1 201) 


Summary: 


User requests fast backward on a paused CoD using trick play in trick play mode 
without reaching the beginning of the recording 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying paused CoD 
(see TD_IMS_IPTV_CoD1_0002) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests x2 fast backward on the paused CoD 


2 


Verify that UE displays images the CoD in fast backward mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast backward on the paused 
CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


RTSP 


UE sends RTSP PLAY (scale -2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays images the CoD in fast backward 
mode 

















4.4.5.6 Jump to specific location in CoD content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0006 (S3A-1 201) 


Summary: 


User jumps to specific point in CoD using trick-play 


References: 


TS 182 027 [1]; TS 183 063 [2] clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, Co 

• UE is re 

• EPG hs 

• UE is d 
(see TC 

• CoDS c 

• IMSCC 

• UEsup 


DS, Core IMS and IPTV AS are configured for method 1 

jgistered in Core IMS using userlPTV_priv identity 

s at least one CoD 

splaying a CoD 

)_IMS_IPTV_CoD1_0001 ) 

onfigured with CoD content 

IRE configured to forward CoD related SIP requests to AS IPTV 

ports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to jump to a specific location in the CoD 


2 


Verify that UE displays the CoD from this specific point 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests to jump to a specific location in 
the CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


RTSP 


UE sends RTSP PLAY (range=z) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays the CoD from this 
specific point 

















4.4.5.7 Quit watching CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0007 (S3A-1 301) 


Summary: 


User quits watching CoD 


References: 


TS 182 027 [1] clause 8.4.3; TS 183 063 [2] clause 5.1.4.4.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User quits watching the CoD 


2 


Verify that UE does not display the CoD anymore 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User quits watching the CoD 


2 
















SIP 


UE sends SIP INFO to CORE via Gm (optional) 






3 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




4 


SIP 


AS sends SIP 200 OK to CORE via 
ISC(optional) 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 
(optional) 






6 


SIP 


UE sends SIP BYE to CORE via Gm 






7 


SIP 


CORE sends SIP BYE to AS via ISC 




8 


SIP 


AS sends SIP BYE to CORE via ISC 




9 


SIP 


CORE sends SIP BYE to CoDS via y2 






10 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






11 


SIP 


CORE sends SIP 200 OK to AS via ISC 




12 


SIP 


AS sends SIP 200 OK to CORE via ISC 




13 
14 


SIP 


CORE sends SIP 200 OK to UE via Gm 
UE does not display the CoD anymore 


<— 
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When a user requests to stop viewing a CoD with the intention of resuming it later, the UE may send a SIP INFO (with 
CoDOffset ) request to the SCF. 

4.4.5.8 Resume CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0008 (S3A-1 401) 


Summary: 


User resumes a CoD from the last watching point 


References: 


TS 182 027 [1] clause 8.3.3; TS 183 063 [2] clauses 5.1.3.4 and 8.1.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• User has stopped watching a CoD prior to its end 
(see TD_IMS_IPTV_CoD1_0007) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to resume a CoD 


2 


Verify that UE displays the CoD from last watching point 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 






1 




j 














User requests to resume a CoD 


2 
















SIP 


UE sends SIP OPTION to CORE via Gm 






3 


SIP 


CORE sends SIP OPTION to AS via ISC 




4 


SIP 


AS sends SIP OPTION to CORE via ISC 




5 


SIP 


CORE sends SIP OPTION to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 






11 


SIP 


CORE sends SIP INVITE to AS via ISC 




12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to CoDS via y2 






14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 




20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to CoDS via y2 






22 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










23 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










24 


SIP 


CoDS sends SIP INFO to CORE via y2 






25 


SIP 


CORE sends SIP INFO to AS via ISC 




26 


SIP 


AS sends SIP 200 OK to CORE via ISC 




27 
28 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE displays the CoD from last watching point 


<— 
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The SIP OPTION message should be used for retrieving the network parameters for SDP when the parameters are not 
included in the SSF. 

The RTSP PLAY message shall carry the range parameter. The range parameter value may be retrieved from the SDP 
h-offset attribute in SIP procedure. Or, the range parameter value may be retrieved from SSF as the service action data 
value of CoDOffset which indicates the last stop point. 

4.4.5.9 CoD termination by IPTV AS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0009 (-) 


Summary: 


IPTV AS stops user from watching CoD 


References: 


TS 182 027 [1] clause 8.4.3; TS 183 063 [2] clause 5.1.4.4.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

• CoDS configured with CoD content 

• IPTV AS provides an interface that allows stopping of CoD provisioning 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


IPTV AS is requested to stop the CoD being watched by user 


2 


Verify that UE stops displaying the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















IPTV AS is requested to stop the CoD being 
watched by user 


2 
















SIP 


AS sends SIP BYE to CORE via ISC (towards 
the CoDS) 




3 


SIP 


CORE sends SIP BYE to CoDS via y2 






4 


SIP 


CoDS sends SIP 200 OK to AS via y2 






5 


SIP 


CORE sends SIP 200 OK to AS via ISC 




6 


SIP 


AS sends SIP BYE to CORE via ISC (towards 
the UE) 




7 


SIP 


CORE sends SIP BYE to UE via Gm 






8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 

10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
UE stops displaying the CoD 


<— 
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4.4.5.10 EndofCoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0010 (-) 


Summary: 


User watches a CoD until its end 


References: 


TS 182 027 [1] clause 8.4.3; TS 183 063 [2] clause 5.1.4.4.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE is registered in Core IMS using userlPTV_priv identity 

• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

• CoDS configured with (short) CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


Verify that UE stops display at end of CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 






(1) 




< 














UE displays CoD 


2 
















RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
via Xc (optional) 










3 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 






4 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 
(optional) 










5 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 




6 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




7 
16 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE stops display at end of CoD 


«— 
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4.4.6 Video on Demand (CoD) using Method 2 



4.4.6.1 Start CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0001 (S3A-1102) 


Summary: 


User watches Video on Demand 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_0001/2/3) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to watch a CoD 


2 


Verify that UE displays the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Three message flows are accepted for this TD. 

1) With SIP re-INVITE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 






1 




v 














User requests to watch a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to CoDS via y2 






22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






27 
















SIP 


CORE sends SIP ACK to AS via ISC 




28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to CoDS via y2 






30 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










31 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










32 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with user related IPTV service action 
data) 






33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






36 




< 














UE displays the CoD 



2) With UPDATE SIP messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to watch a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP UPDATE to CORE via Gm 






19 


SIP 


CORE sends SIP UPDATE to AS via ISC 




20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to CoDS via y2 






22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










27 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










28 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional, with user related IPTV service action 
data) 






29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






30 
















SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






32 




< 














UE displays the CoD 



3) With RTSP Channel establishing without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to watch a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with user related IPTV service action 
data) 






19 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




20 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




21 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






22 




< 














UE displays the CoD 
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4.4.6.2 Pause CoD with trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0002 (S3A-1 201) 


Summary: 


User pauses a CoD using trick-play 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to pause CoD 


2 


Verify that UE freezes the image of the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to pause CoD 


2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 










3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
UE freezes the image of the CoD 


«— 













4.4.6.3 Play CoD with trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0003 (S3A-1 201) 


Summary: 


User plays a CoD using trick-play 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, Co 

• UE is re 

• EPG ha 

• UE is in 
(see TC 

• CoDS c 

• IMSCC 

• UEsup 


DS, Core IMS and IPTV AS are configured for method 1 

jgistered in Core IMS using userlPTV_priv identity 

s at least one CoD 

pause mode watching a CoD 

_IMS_IPTV_CoD2_0002) 

onfigured with CoD content 

IRE configured to forward CoD related SIP requests to AS IPTV 

ports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to play the paused CoD 


2 


Verify that UE displays the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




> 














User requests to play the paused CoD 


2 




< 












RTSP 


UE sends RTSP PLAY to CoDS via Xc 










3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
Verify that the UE displays the CoD 











4.4.6.4 Fast forward CoD using trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0004 (S3A-1 202) 


Summary: 


User fast forwards CoD using trick play 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0003) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to x2 fast forward CoD 


2 


Verify that UE displays images the CoD in fast forward mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 






1 




v 














User requests to fast forward CoD 


2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays images the CoD in fast forward 
mode 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.5 Fast backward CoD using trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0005 (S3A-1 202) 


Summary: 


User fast backwards CoD using trick play 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0003) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to x2 fast backward CoD 


2 


Verify that UE displays images the CoD in fast backward mode 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to fast backward CoD 


2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY (scale -2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays images the CoD in fast 
backward mode 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.6 Jump to specific location in CoD content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0006 (S3A-1 202) 


Summary: 


User jumps in CoD to specific point using trick-play 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0002) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to jump to a specific location in the CoD 


2 


Verify that UE displays the CoD from this specific point 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















User requests to jump to a specific location in 
the CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY (range=z) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays the CoD from this 
specific point 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.7 Terminate CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0007 (S3A-1 302) 


Summary: 


User quits watching CoD 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0003) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User quits watching the CoD 


2 


Verify that the UE does not display the CoD anymore 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Two message flows are accepted for this TD. 

1) With SIP messages exchange initiated by UE: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User quits watching the CoD 


2 
















SIP 


UE sends SIP INFO to CORE via Gm 






3 


SIP 


CORE sends SIP INFO to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 


RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 










7 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










8 


SIP 


UE sends SIP BYE to CORE via Gm 






9 


SIP 


CORE sends SIP BYE to AS via ISC 




10 


SIP 


AS sends SIP BYE to CORE via ISC 




11 


SIP 


CORE sends SIP BYE to CoDS via y2 






12 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 




14 


SIP 


AS sends SIP 200 OK to CORE via ISC 




15 
16 


SIP 


CORE sends SIP 200 OK to UE via Gm 
UE does not display the CoD anymore 


<— 
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2) With SIP messages exchange initiated by CoDS: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User quits watching the CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP TEARDOWN to MVS via Xc 










5 


SIP 


CoDS sends SIP INFO (with CoDOffset) to 
CORE via y2 (optional) 






6 


SIP 


CORE sends SIP INFO to AS via ISC 




7 


SIP 


AS sends SIP 200 OK to CORE via ISC 




8 


SIP 


CORE sends SIP 200 OK to CoDS via y2 






9 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










10 


SIP 


UE sends SIP BYE to CORE via Gm 






11 


SIP 


CORE sends SIP BYE to AS via ISC 




12 


SIP 


AS sends SIP BYE to CORE via ISC 




13 


SIP 


CORE sends SIP BYE to CoDS via y2 






14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 




« 1 














UE does not display the CoD anymore 
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4.4.6.8 Resume CoD 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0008 (S3A-1 402) 


Summary: 


User resumes a CoD from the last watching point 


References: 


TS 182 027 [1] clause 8.4.1 ; TS 183 063 [2] clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• User has stopped watching a program prior to its end 
(see TD_IMS_IPTV_CoD2_0006) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


User requests to resume a CoD 


2 


Verify that UE displays the CoD from last watching point 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Three message flows are accepted for this TD. 



1) Using SIP re-INVITE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to resume a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to CoDS via y2 






22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 
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Step 


Direction 


Protocol 


Comment 
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S 


C 



D 
S 






28 
















SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to CoDS via y2 






30 


RTSP 


UE sends RTSP PLAY (with range parameter) 
to CoDS via Xc 










31 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










32 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 






33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






36 




< 














UE displays the CoD from last watching point 



Note that the range parameter value in step 30 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, 
the range parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the 
last stop point. 

2) Using SIP UPDATE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




> 














User requests to resume a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP UPDATE to CORE via Gm 






19 


SIP 


CORE sends SIP UPDATE to AS via ISC 




20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to CoDS via y2 






22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY (range parameter) to 
CoDS via Xc 










27 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 















ETSI 



53 



ETSI TS 186 020 V2.1.1 (2009-12) 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






28 
















SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 






29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




30 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






32 




< 














UE displays the CoD from last watching point 



Note that the range parameter value in step 26 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, 
the range parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the 
last stop point. 

3) Using RTSP channel establishment without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to resume a CoD 


2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP PLAY(with range parameter) to 
CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 






19 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




20 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




21 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






22 




< 














UE displays the CoD from last watching point 



The range parameter value in step 16 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, the range 
parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the last stop 
point. 
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4.4.6.9 CoD termination by IPTV AS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0009 (S3A-1 402) 


Summary: 


AS IPTV stops user from watching CoD 


References: 


TS 1 82 027 [1 ] clause 8.4. 1 ; TS 1 83 063 [2] clause 5.1 .4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001) 

• CoDS configured with CoD content 

• IPTV AS provides an interface that allows stopping of CoD provisioning 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


IPTV AS is requested to stop ongoing CoD 


2 


Verify that UE stops displaying the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














1 


















IPTV AS is requested to stop ongoing CoD 


2 
















SIP 


AS sends SIP BYE to CORE via ISC 




3 


SIP 


CORE sends SIP BYE to UE via Gm 






4 


RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










6 


RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 










7 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with CoDOffset) 






8 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




9 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




10 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






11 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










12 


SIP 


UE sends SIP 200 OK to CORE via Gm 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 




14 


SIP 


AS sends SIP BYE to CORE via ISC 




15 


SIP 


CORE sends SIP BYE to CoDS via y2 






16 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






17 

18 


SIP 


CORE sends SIP 200 OK to AS via ISC 
UE stops displaying the CoD 


<— 
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4.4.6.1 CoD termination at the end of stream 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 00010 (S3A-1 701) 


Summary: 


User watches a CoD until its end 


References: 


TS 182 027 [1] clause 8.4.1 ; TS 183 063 [2] clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001) 

• CoDS configured with (short) CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


Test Sequence: 


Step 




1 


Verify that the UE stops at end of CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Two message flows are accepted for this TD. 

1) Using SIP INFO and RTSP ANNOUNCE messages: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


C 



D 
S 














(1) 




C 














UE displays CoD 


2 
















RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
viaXc 










3 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 






4 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 
(optional) 










5 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 




6 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




7 


SIP 


CORE sends SIP 200 OK to CoDS via y2 






8 


SIP 


UE sends SIP INFO to CORE via Gm 
(optional) 






9 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




10 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




11 
12 


SIP 


CORE sends SIP 200 OK to UE via Gm 

(optional) 

UE stops CoD 


<— 
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2) With SIP INFO messages on receiving RTSP TEARDOWN: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






(1) 




^ 














UE displays CoD 


2 
















RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
via Xc 










3 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 










4 


RTSP 


UE sends RTSP PAUSE to CoDS via Xc (optional) 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc (optional) 










7 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 






8 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 




9 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




10 
11 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE stops CoD 


<— 

















4.4.7 



NPVR using Method 1 



4.4.7.1 Impulsive recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP1 0001 (S3A-1901) 


Summary: 


User requests an impulsive recording of a broadcast TV channel 


References: 


TS 182 027 [1] clause 8.5; TS 183 063 [2] 


Configuration: 


CF IMS IPTV 


Required Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


Pre-test conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTVpriv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is displaying broadcast TV channel 
(see TD_IMS_IPTV_BC_0001 ) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to 
AS IPTV 

• UE, PVRS and TV Head End support the same content protocols 
and coding 


Test Sequence: 


Step 




1 


User requests an impulsive 
recording of a broadcast TV 
channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end 
of the recorded program 


4 


Verify that UE displays EPG with 
the new entry 


Conformance Criteria: 


Check 




1 


Message exchange follows the 
below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests an impulsive recording of a 
broadcast TV channel 




2 
















SIP 


UE sends SIP MESSAGE (bookmark) to CORE 
via Gm 






3 


SIP 


CORE sends SIP MESSAGE (bookmark) to AS 
via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






I 
















SIP 


AS sends SIP to CORE via ISC immediately 
(not described in R2) 




i 


SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






I 
















IGMP Join 


PVRS starts recording TV Channel program 
(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 
the end of the program 
(not described in R2) 








7 
















SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 
14 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

UE displays EPG with the new entry 


<— 















Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 

Steps 1 1 and 12 allows UE to get TV content captured in steps "i" as described in clause 8.5.2 of [1]. 

4.4.7.2 Scheduled recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP1 0002 (S3A-2001) 


Summary: 


User requests a scheduled recording of a broadcast TV channel 


References: 


TS 1 82 027 [1 ] clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• UE, PVRS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is not displaying broadcast TV channel 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 
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Interoperability Test Description 


Test Sequence: 


Step 




1 


User requests a scheduled recording of a broadcast TV channel 


2 


Verify that UE confirms parking 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with the new entry 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests a scheduled recording of a 
broadcast TV channel 




2 
















SIP 


UE sends SIP MESSAGE to CORE via Gm 






3 


SIP 


CORE sends SIP MESSAGE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






I 
















SIP 


AS sends SIP to CORE via ISC 
(not described in R2) 




i 


SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






I 


IGMP Join 


PVRS starts recording TV Channel program, at 

"start-time" 

(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 

"end-time" 

(not described in R2) 








7 
















SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








14 




< — 
























UE displays EPG with the new entry 



Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 
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4.4.7.3 Watching a recorded nPVR content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP1 0003 (S3A-2201) 


Summary: 


User watches a recorded content 


References: 


TS 1 82 027 [1 ] clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, PVRS 


Pre-test 
conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• nPVR content is available in PVRS based on either an impulsive or scheduled 
request to capture broadcast TV channel (see TD_IMS_IPTV_nP1_0001/2) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 






1 


User requests to watch recorded content 




2 


Verify that UE displays recorded content 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


P 
V 
R 
S 














1 




» 














User requests to watch recorded content 


2 
















SIP 


UE sends SIP OPTION to CORE via Gm 

(to retrieve parameters to build SDP - optional) 






3 


SIP 


CORE sends SIP OPTION to AS via ISC 
(optional) 




4 


SIP 


AS sends SIP OPTION to CORE via ISC 
(optional) 




5 


SIP 


CORE sends SIP OPTION to PVRS via y2 
(optional) 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 
(optional) 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional) 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 
(optional) 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 






11 


SIP 


CORE sends SIP INVITE to AS via ISC 




12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to PVRS via y2 






14 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 




20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to PVRS via y2 






22 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










23 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 






24 
















SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 






25 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




26 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




27 
28 


SIP 


CORE sends SIP 200 OK to PVRS via y2 

(optional) 

UE displays the recorded content 


<— 

















4.4.8 NPVR - Method 2 



4.4.8.1 Impulsive recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP2 0001 (S3A-1902) 


Summary: 


User requests to park and pickup a broadcast TV channel 


References: 


TS 1 82 027 [1 ] clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


Pre-test conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is displaying broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to 
AS IPTV 

• UE, PVRS and TV Head End support the same content protocols 
and coding 


Test Sequence: 


Step 




1 


User requests an impulsive recording of a broadcast TV 
channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with new entry 


Conformance Criteria: 


Check 




1 


Message exchange follows the below table 



The message flow is divided into two phases. The first one corresponding to the park request is given below: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 
O 
R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests an impulsive recording of a 
broadcast TV Channel 




2 
















SIP 


UE sends SIP MESSAGE to CORE via Gm 






3 


SIP 


CORE sends SIP MESSAGE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 




i 














UE confirms parking 


i 
















SIP 


AS sends SIP to CORE via ISC immediately 
(not described in R2) 





















ETSI 



61 



ETSI TS 186 020 V2.1.1 (2009-12) 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


u 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 






i 
















SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






i 


IGMP Join 


PVRS starts recording TV Channel program 
(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 
the end of the program 
(not described in R2) 








7 
















SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end time of 
program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 
14 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

UE displays EPG with new entry 


S- 















Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 

4.4.8.2 Scheduled recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP2 0002 (S3A-2102) 


Summary: 


User requests the scheduled recording of a broadcast TV channel 


References: 


TS 1 82 027 [1 ] clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• UE, PVRS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is not displaying broadcast TV channel 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 




1 


User requests the scheduled recording of a broadcast TV channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with new entry 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests the scheduled recording of a 
broadcast TV channel 




2 
















SIP 


UE sends SIP MESSAGE to CORE via Gm 






3 


SIP 


CORE sends SIP MESSAGE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






i 
















SIP 


AS sends SIP to CORE via ISC 
(not described in R2) 




i 


SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






i 


IGMP Join 


PVRS starts recording TV Channel program, at 
"start-time" (not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 
"end-time" (not described in R2) 








7 
















SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








14 




< — 
























UE displays EPG with new entry 



The AS-IPTV may send additional MESSAGES to the UE to inform something, such as the current recording status. 

4.4.8.3 Watching a recorded content 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP2 0003 (S3A-2202) 


Summary: 


User watches a recorded nPVR content 


References: 


TS 1 82 027 [1 ] clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, PVRS 


Pre-test 
conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• nPVR content is available in PVRS based on either an impulsive or offline request 
to capture broadcast TV channel (see TD_IMS_IPTV_nP2_0001/2) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 






1 


User requests to watch the captured nPVR content 




2 


Verify that UE displays the captured nPVR content 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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There are 3 accepted different possibilities for playing the recorded content: 

1) With relnvite SIP messages for establishing the content delivery channel: 



Step 


Direction 


Protocol 


Comment 




U 
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& 
A 
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E 


A 
S 


P 
V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to PVRS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 










17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to PVRS via y2 






22 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 




28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to PVRS via y2 






30 


RTSP 


UE sends RTSP PLAYto PVRS via Xc 










31 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










32 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 






33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






36 




< 














UE displays the recorded nPVR content 
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2) With UPDATE SIP messages for establishing the content delivery channel: 



Step 


Direction 


Protocol 


Comment 




U 
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S 
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V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to PVRS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 










17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










18 


SIP 


UE sends SIP UPDATE to CORE via Gm 






19 


SIP 


CORE sends SIP UPDATE to AS via ISC 




20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to PVRS via y2 






22 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










27 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










28 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 






29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




30 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






32 




« 














UE is displaying the recorded nPVR content 
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3) With RTSP Channel establishing without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
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r 
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A 
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S 
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V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 
















SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 






14 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 










15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










18 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 






19 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




20 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




21 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






22 




< 














UE is displaying the recorded nPVR content 
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Annex A (informative): 
Bibliography 

IETF RFC 4566: "SDP: Session Description Protocol". 
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